A portal is generally synonymous with a gateway for a website that is or proposes to be a major starting site for users when they get connected to the Web or tend to use an enterprise-level software solution. Portal performance is usually measured by the amount of time required to actually render that portal and all of its constituent parts once a visitor sends a request to a portal-side managing component for the portal such as a portal servlet by, for a non-limiting example, clicking an object on the screen. Any number of reasons can negatively impact the anticipated performance of the portal. Like any other software product, portal's performance problems may not be the result of flaws in the product itself but rather the result of poor decisions made during the design phase of the portal, such as its layout and design, which directly affect its performance. Proper planning would allow a user to take advantage of the inherent strengths of product to ensure optimal performance for the portal.
A portal may execute three main operations to serve a portal request via its controls:                When a portal is instantiated, a meta control hierarchy (which can be a meta control tree) can be created from, for a non-limiting example, an XML markup file that represents the portal and cached (if the tree has not been cached earlier). Each node in the hierarchy (tree) represents a control and its information such as control's subclass name and set of (properties) name/value pairs. The more controls the portal has, the larger its control tree, is going to be. FIG. 1 depicts an exemplary control tree of a portal with 1 desktop, creates 1 main book, 40 books, 400 pages and 4000 portlets, a total of 4442 controls (nodes). The inclusion of buttons, windows, menus, and layouts will increase the number of controls on the portal significantly.        Upon every request from a user, a control tree can be created from the meta control tree, and cannot be reused to serve subsequent requests. Note that all nodes in the meta control tree are of the same type, while the control tree may contain different types of nodes.        Once the control tree is built, control lifecycle stages are run on every control in the tree before the portal can be fully-rendered. The stages of the lifecycle include but are not limited to, init, load, loadState/handlePostback, raiseChangeEvents, preRender, saveState, render and destroy as shown in FIG. 2. The control lifecycle will skip loadState/handlePostback, and raiseChangeEvents stages for a new request but runs them for a post back request that has been served. The preRender and render stages are skipped for non-visible controls. The stages can be called on each control in a depth-first order, i.e., all initialization methods such as init( ) are invoked followed by state loading method such as loadState( ) and the lifecycle may proceed in an order determined by the position of each control in the portal's meta control tree. For a non-limiting example, the exemplary control tree illustrated in FIG. 3 depicts the taxonomy of a simple portal comprised of a book (B1) containing two pages (P1 and P2), which each contain two portlets (p1-p4) and p2 also contains its own subordinate book, page, and portlet hierarchy. When this portal is rendered, the initialization method will be called first for each control in the order of: B1, P1, p1, p2, B2, P3, p5, p6, P2, p3, and finally p4. Next, the state loading method would be called in the same order, and all lifecycle methods through state save will be called eventually.        
One of the most significant impediments to portal performance lies with the number of controls (resources) on a portal, wherein the controls can include but are not limited to, desktops, books, pages, and portlets. Portal consumes CPU time mainly to create a new control tree, to run control lifecycle stages, and garbage collection of control tree objects that are discarded after serving a request. Such overhead of processing time can grow exponentially for a typical portal having thousands of controls as the portal's throughput (pages/sec) is inversely proportional to the size of a portal i.e. number of books, pages, and portlets. Consequently, the larger the size of the portal's control tree, the greater the hit will be on portal performance. As large portals are being built, performance and scalability of the portal needs to be improved.